-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Components: Allow to apply isPressed prop to Button and SVG components to indicate the state of the button #17748
Conversation
I'm curious whether #17719 (comment) will help here as well.
|
4eb89cc
to
021fea3
Compare
@gziolo - #17228 On its own won't solve the wordpress-mobile/gutenberg-mobile#1398 issue. |
Thank you. I will resume my explorations next week after WP 5.3 RC1 is out. I really need to spin off a native app to dive deeper 👍 |
Thanks for the help @gziolo and please let me know if you need any support/help with running/building native app. |
aa49770
to
76648d9
Compare
76648d9
to
4f4821b
Compare
62b14a8
to
e8e0175
Compare
f4ddd55
to
88599b3
Compare
I managed to fix the specificity issue with the color picker button in a5ef4c2. This is how it looks like now: |
@gziolo - Testing with current I did a smoke test. Now I will continue testing and checking code more closely to be sure, and come back with a final result 👍 |
a5ef4c2
to
71d69af
Compare
I renamed this prop from |
@@ -134,7 +134,7 @@ Name | Type | Default | Description | |||
`isDestructive` | `bool` | `false` | Renders a red text-based button style to indicate destructive behavior. | |||
`isLarge` | `bool` | `false` | Increases the size of the button. | |||
`isSmall` | `bool` | `false` | Decreases the size of the button. | |||
`isToggled` | `bool` | `false` | Renders a toggled button style. | |||
`isPressed` | `bool` | `false` | Renders a pressed button style. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't keep the old name because it only applied the is-toggled
class name which was never styled. I can bring it back, but I don't feel like it's a good idea to keep it. It's only confusing.
const tagProps = tag === 'a' ? { href, target } : { type: 'button', disabled }; | ||
const tagProps = tag === 'a' ? | ||
{ href, target } : | ||
{ type: 'button', disabled, 'aria-pressed': isPressed }; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have default styles for the isPressed variation of the Button
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As commented: no, we don’t, we should do it as the follow up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like isBoolean
is the convention adopted by Gutenberg, right? Should disabled
be isDisabled
as well? I see that both are used in the project (for example, ToolbarButton
currently accepts isDisabled
and passes it to the disabled
prop on Button
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aduth - do you have recommendations here? I don't think we made it the rule. I'm happy to open a follow-up to update if necessary. disabled
will always work because it's HTML attribute ... but it would be nice to follow conventions.
I also want to have isFocusable
prop so we don't have to use <Button aria-disabled={ true } />
as a workaround for <Button isDisabled isFocusable />
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I used to prefer the un-prefixed disabled
over an isDisabled
, given that it aligned better with expectations around how attributes apply to HTML elements, but over time I've come to regard this as an alignment that we shouldn't want to try to reinforce. In the worst case, it can mislead a developer to think that their disabled
prop would be guaranteed to apply a disabled
HTML attribute somewhere, which isn't always the case (we should embrace that a component can be an abstraction not directly tied to some specific DOM implementation). Conversely, we lose any benefit that we can gain from "signalling" an expected prop value; a prop named foo
could be interpreted to be any value, but an equivalent isFoo
is more clearly expecting a boolean.
My recommendation would be to prefer to name new boolean props using the isFoo
convention.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Still hesitant between isToggled or isPressed and I feel the button component should have default styles for these.
https://material-ui.com/api/toggle-button/ - they use selected prop for the active state Naming is hard. The aria way to mark active/selected/pressed is aria-pressed 😅
I agree but I also don’t seem to be the best skilled person to perform this refactor. |
When in doubt, I always refer to the ARIA spec since they've already done a good job on naming things. So I agree with @gziolo on |
a282f31
to
28644e7
Compare
28644e7
to
cdc9788
Compare
This is a common misconception. The
I'm seeing this attribute is now used inappropriately in some cases and in other cases it's used in combination with |
Description
This PR promotes
__unstableActive
prop fromSVG
component to the stable prop calledisToggled
. It reflects that it relates to the toggled state of the button. This is mostly for the usage in mobile apps, but it also exposedis-toggled
class name for the web to make styling easier.At the same time this PR refactors code to use
isToggled
prop is used consistently for allButton
components and it's variations likeIconButton
. This ensures that the same CSS class name is used in all places –is-toggled
andaria-pressed
is provided in case whenisToggled
is set totrue
for DOM elements making them more accessible.Testing
There should be no difference in how the web and mobile apps operate. All buttons should look and behave the same.
UI elements to test:
URLInputButton
- never used in the codeEdit image
button in the toolbarDateTime
components - AM/PM switch